DEPS: Bump optional dependencies #62241
Conversation
This reverts commit 0dbf92e.
pandas/core/arrays/string_arrow.py
Outdated
| def _str_removeprefix(self, prefix: str): | ||
| if not pa_version_under13p0: | ||
| return ArrowStringArrayMixin._str_removeprefix(self, prefix) | ||
| return super()._str_removeprefix(prefix) | ||
| return ArrowStringArrayMixin._str_removeprefix(self, prefix) |
There was a problem hiding this comment.
If it becomes just calling the other method, I think you can add it as a simple _str_removeprefix = ArrowStringArrayMixin._str_removeprefix to the list of such assignments a bit above
pandas/core/arrays/string_arrow.py
Outdated
| and not (start == 0 and end is None) | ||
| ): | ||
| # GH#59562 | ||
| return super()._str_find(sub, start, end) | ||
| return ArrowStringArrayMixin._str_find(self, sub, start, end) |
|
What's in general your rationale for deciding how to update the versions? (and do we have some policy about this written somewhere?) For Python and numpy I think we follow SPEC0, but for example scipy and xarray are also listed there and you updated them to a more recent version (for example for xarray, the new minimum version 2024.10.0 is less than one year old. Or is the idea that by the time 3.0 is released it will be >= 1 year old? But for a package like xarray, where we don't have that much custom code, it seems also easy to keep two years of support to follow SPEC0, causing less compatibility issues for people installing pandas with a mix of versions). In any case, I think most of the actual code changes are related to pyarrow (and some forgotten numpy backcompat code), and that update is definitely fine, since we have a clear 2 year support window there which means we can bump to 13.0 (and that is also a useful update given the amount of special cases we had for that) |
I've been setting the minimum tested versions to ~1 year old for optional dependencies and ~2 years old for required dependencies by the time the next major/minor version of pandas is released (e.g. hopefully October or Q4 for pandas 3.0). I don't think I've documented this anywhere but I can add a note in It appears we've documented that we follow SPEC0 for Python support, but I suppose we implicitly also follow it for Numpy? https://pandas.pydata.org/docs/dev/development/policies.html#policies-python-support |
|
Merging, but happy to follow up if needed |
Also defined
PYARROW_MIN_VERSIONso it can be shared in our error message if pyarrow doesn't meet our minimum version